「AI 不會取代自動化測試工程師（SDET）；但懂用 AI 的 SDET，將會全面取代還在純手動寫 3000 行 Page Object 的工程師。」

大家好，我是 Jane，一個每天在第一線處理跨平台（Web & App）自動化測試、跟 CI/CD Pipeline 與前沿技術（AI in Testing）奮戰的自動化測試工程師（SDET）。

在上集 Day 28 中，我們制定了舊測試框架重構的 5 階段藍圖，學會了如何優雅地清除技術債。

來到 2026 年，整個軟體工程領域變化最快的，莫過於生成式 AI（LLM）與 AI Agent 在自動化測試中的落地。

許多剛接觸 AI 工具的 QA 常會有兩個極端的誤解：

1. 極端樂觀：「AI 太厲害了！只要對它說一句『幫我測試這個網站』，它就能自動幫我寫出 100% 完美的 pytest 腳本！」
2. 極端悲觀：「AI 產出的程式碼充滿幻覺（Hallucination），Locator 常常瞎編、斷言（Assert）全寫錯，根本不能用在正式 CI/CD 裡！」

身為第一線把關品質的 SDET，我們到底該如何理性、高效地把 AI 工具整合進 Python/pytest 自動化測試體系中？

今天這篇文章，我們就來好好剖析：AI 可以在自動化測試的哪 4 個環節發揮 10x 效能？以及我們該如何防範 AI 帶來的『幻覺陷阱』！

一、 AI 在自動化測試的 4 大落地場景（Use Cases）

                    ┌─────────────────────────┐
                    │    AI 輔助測試 4 大場景  │
                    └────────────┬────────────┘
                                 │
     ┌───────────────────────────┼───────────────────────────┐
     ▼                           ▼                           ▼
1. API 契約與 Schema 產生       2. Page / Component 生成    3. 測試資料動態生成 (Data)  
4. 失敗 Log 根因診斷 (RCA)

1. API 契約與 Schema 自動生成 (API Schema Generation)

給予一段 OpenAPI / Swagger 規格文件或是 HTTP Response JSON，讓 AI 在 5 秒內精準生成 Pydantic Schema（Day 20）與 pytest 測試範本。

2. 輔助 Page / Component Object 骨架撰寫 (Boilerplate Code)

貼上前端的 DOM 結構或是 React 元件原始碼，讓 AI 自動提取語意化的 data-testid 或 get_by_role 定位器，並組裝成物件類別。

3. 動態測試資料邊界生成 (Test Data & Edge Cases)

利用 LLM 針對業務邏輯生成極端邊界值（如：各國特殊字元姓名、跨時區日期格式、SQL Injection/XSS 測試字串），充實我們的 Data Factory（Day 17）。

4. CI 失敗 Log 根因分析 (RCA - Root Cause Analysis)

在 CI Pipeline 失敗時，將控制台輸出、Playwright Trace 錯誤與 API Response 餵給 AI，讓 AI 快速摘要出「這是 DOM 超時、500 伺服器錯誤還是邏輯斷言失敗」。

二、 Python / pytest 實戰：利用 OpenAI / LLM API 自動化產生測試

我們來寫一個極度實用的腳本：當我們輸入一個 API Response 的 JSON 時，利用 Python 腳本呼叫 LLM，自動生成對應的 Pydantic Schema 與 pytest 測試程式碼！

1. 撰寫 AI 測試生成工具 (scripts/ai_test_generator.py)

Python

# scripts/ai_test_generator.py
import json
import os
from openai import OpenAI

# 初始化 OpenAI Client
client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

PROMPT_TEMPLATE = """
你是一個資深的 Python SDET 工程師。請根據以下提供 API Response JSON，
為我生成符合的最佳實踐代碼：
1. 使用 Pydantic (v2) 定義嚴謹的 Response Schema (包含欄位型態與 Optional 處理)。
2. 使用 pytest + requests 撰寫一個完整測試函式。
3. 斷言必須包含 Schema 驗證與狀態碼 200 檢查。

API Response JSON:
{json_data}

請僅回傳乾淨的 Python 程式碼，不要包含額外的說明文字。
"""

def generate_pytest_code(json_str: str) -> str:
    """呼叫 LLM 根據 JSON 自動生成 pytest 程式碼"""
    prompt = PROMPT_TEMPLATE.format(json_data=json_str)

    response = client.chat.completions.create(
        model="gpt-4o",  # 或使用當前最新的 LLM 模型
        messages=[{"role": "user", "content": prompt}],
        temperature=0.2  # 低隨機性，確保程式碼結構穩定
    )

    return response.choices[0].message.content

if __name__ == "__main__":
    sample_json = json.dumps({
        "status": "success",
        "data": {
            "user_id": "USR_9981",
            "email": "jane_sdet@example.com",
            "is_vip": True,
            "orders_count": 5
        }
    })

    generated_code = generate_pytest_code(sample_json)
    print("=== AI 自動生成的 pytest 程式碼 ===")
    print(generated_code)

2. AI 生成的合格程式碼範例

執行上述腳本後，AI 會產出以下乾淨且可執行的程式碼：

Python

# 由 AI 自動生成的測試代碼
import pytest
import requests
from pydantic import BaseModel, EmailStr, Field

# 1. AI 自動生成的 Pydantic Schema
class UserDataSchema(BaseModel):
    user_id: str
    email: EmailStr
    is_vip: bool
    orders_count: int = Field(ge=0)

class ApiResponseSchema(BaseModel):
    status: str
    data: UserDataSchema

# 2. AI 自動生成的 pytest 測試案例
def test_user_api_schema_generated_by_ai(api_base_url, auth_headers):
    response = requests.get(f"{api_base_url}/api/v1/user/profile", headers=auth_headers)

    assert response.status_code == 200

    # 執行 Pydantic Schema 結構與型態校驗
    validated_data = ApiResponseSchema(**response.json())
    assert validated_data.status == "success"
    assert validated_data.data.is_vip is True

三、 第一線 SDET 必須防範的「AI 3 大幻覺陷阱」

雖然 AI 能將樣板程式碼（Boilerplate Code）的撰寫速度提升 5 倍，但 SDET 必須擔任最後的 Human-in-the-loop（人工審核） 防線：

1. 陷阱 1：無效的斷言（Trivial / False-Positive Assertions）
   AI 常常會寫出 assert True 或 assert response.status_code != 500 這類看似有寫、實則無法捕捉商業 Bug 的無效斷言。
2. 陷阱 2：虛構的 DOM 定位器（Hallucinated Locators）
   在寫 Web / App UI 測試時，AI 經常憑空捏造不存在的 CSS Class 或 ID（例如 #submit-btn-v2）。永遠要在真實瀏覽器中驗證 Locators 的存在！
3. 陷阱 3：缺乏環境與生命週期維護（Ignoring Fixture & State）
   AI 產出的程式碼往往假設「環境裡已經有現成的資料」。SDET 必須手動將其改寫為搭配 conftest.py Fixture 的動態 Teardown 架構（Day 17）。

四、 第一線 SDET 的 AI 心法

• 把 AI 當成「高效率的實習生」：它可以幫你處理 80% 繁瑣、重複的語法撰寫與 Schema 轉換，但 20% 核心的商業 logic 斷言、測試架構設計與品質防線劃分，依然掌握在資深 SDET 手中。
• 將 Prompt 提示詞程式碼化（Prompt Infrastructure）：把常用來生成測試的 Prompt 寫成 Team-level 的範本（Prompt Templates），確保全團隊產出的 AI 測試程式碼風格與命名規範保持一致。

明日預告

恭喜大家完成了前 29 天的精彩旅程！

明天，我們將來到整個 30 天鐵人賽系列文章的最高潮與完結篇：
《 Day 30｜測試自動化的終極目標：建構可信任的品質平台與 SDET 的職涯進化 》。

明天 Day 30，我們將為整個 30 天的自動化測試體系劃上完美的句點，並一起展望跨平台自動化測試工程師（SDET）的未來！